Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Eric Levy-Abegnoli

dblp:37/1517 · DBLP profile ↗
← Back
3ranked-venue papers
1as first author
0since 2021 · last 2002
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Computer networks · 2 · 1 first-authorSoftware engineering, systems software and programming languages · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
1 paper
Cloud and datacenter computing · 50% Memory systems · 50%
Software engineering, system software, and programming languages
1 paper
Operating systems · 100%

Topics — the 3 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Memory systems
cache
0.011999
Design and Performance of a Web Server Accelerator · INFOCOM 1999
Cloud and datacenter computing › datacenter services › online service systems › internet services
web server
0.011999
Design and Performance of a Web Server Accelerator · INFOCOM 1999
Operating systems › special-purpose operating system
embedded operating system
0.011999
Design and Performance of a Web Server Accelerator · INFOCOM 1999

Methods — techniques the papers use, named apart from their topics

caching API · 0.0
YearPublicationVenuePosition
2002 Architecture of a Web server accelerator
Junehwa Song, Arun Iyengar, Eric Levy-Abegnoli, Daniel M. Dias
Comput. Networks3
2000 Design alternatives for scalable Web server accelerators
abstract
We study design alternatives for, and describe implementations and performance of, a scalable and highly available Web server accelerator. The accelerator runs under an embedded operating system and improves Web server performance by caching data. The basic design alternatives include a content router or a TCP router (without content routing) in front of a set of Web cache accelerator nodes, with the cache memory distributed across the accelerator nodes. Content based routing reduces cache node CPU cycles but can make the front-end router a bottleneck. With the TCP router, a request for a cached object may initially be sent to the wrong cache node; this results in larger cache node CPU cycles, but can provide a higher aggregate throughput, because the TCP router becomes a bottleneck at a higher throughput than the content router. Based on measurement of implementations, we quantify the throughput ranges in which different designs are preferable. We also examine a combination of content based and TCP routing techniques. We examine optimizations, such as different communication and data delivery methods, replication of hot objects, and cache replacement policies that take into account the fact that there might be different bottlenecks in the system at different times; depending upon which resource is likely to become a bottleneck, a different cache replacement algorithm is applied.
Junehwa Song, Eric Levy-Abegnoli, Arun Iyengar, Daniel M. Dias
ISPASS2
1999 Design and Performance of a Web Server Accelerator
abstract
We describe the design, implementation and performance of a Web server accelerator which runs on an embedded operating system and improves Web server performance by caching data. The accelerator resides in front of one or more Web servers. Our accelerator can serve up to 5000 pages/second from its cache on a 200 MHz PowerPC 604. This throughput is an order of magnitude higher than that which would be achieved by a high-performance Web server running on similar hardware under a conventional operating system such as Unix or NT. The superior performance of our system results in part from its highly optimized communications stack. In order to maximize hit rates and maintain updated caches, our accelerator provides an API which allows application programs to explicitly add, delete, and update cached data. The API allows our accelerator to cache dynamic as well as static data, analyze the SPECweb96 benchmark, and show that the accelerator can provide high hit ratios and excellent performance for workloads similar to this benchmark.
Eric Levy-Abegnoli, Arun Iyengar, Junehwa Song, Daniel M. Dias
INFOCOM1